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H ydra: Real-Time Physic al Architecture 

Distributor: journals network requests and 
hashes request ID (IMSI, mall address, 
account number) to find correct logical 
then physical Consumer Directory 










© Con /erg vs. 2002 


Confidential 


CONVERGES 



Figure 17 



CinLibrary/1221 196.4 



Hydra: Real-Time Phy sical Architecture 

Consumer Directory: lookup from request ID to 
determine the logical server to process the request, 
and the associated logical data store. Directory pre- 
loaded from Consumer Databases. 
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Hydra: Re al-Time Physical Arch jtecture 
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Consumer Databases: Stores product instances and 
associated Consumer ID and wallet allowances. 
Does not store wallet values. 
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Hydra: Real-Time Ph ysical Architecture 

Consumer Databases: Implemented as a large number 

of logical databases partitioned onto asmaller 
number of physical databases. Accessed via database 
proxy (not shown). 
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Hydra: Real-Time Physical Architecture 
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Hydra: Real-Time Physical Architecture 



Consumer Server: Demand read of customer and wallet 
consumption data from Customer Database not already 
preloaded Into the Consumer Server cache. 
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Hydra: Real-Time Physical Architecture 
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Reference Database: all reference data 
(product, and wallet details) normally 
preloaded into Consumer Server (demand 
loadin g also sup ported) 
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Hydra: Real-Time Physi cal Architecture 

Wallet Server: maintains master copy of wallet for a 
given period. Creates slave wallets (and and loans) for 
each Consumer Server (normally prior to event arrival). 
Wallets inhialy created using information in Consumer 
Databases and Reference Database. 
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Hydra: Real-Time Physical Architecture 

Wallet Databases: Persistent storage for Wallets 
across system restart and Wallet Server failure. 
Implemented as a number of logical databases spread 
across a smaller number of physical databases. 
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Hydra: Real-Time Physical Architecture 

* fnncumer Server: 
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Hydra: Real-Time Physical Architecture 
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rhiirne details and updated consumer server wallet 
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Hydra: Real-Time Physical Architecture 



Event Manager: Reads log information written by the 
consumer server. Distributes event and charges to 
downstream systems. Events are sent to the event store, and 
updated balance information is passed to the Wallet Server. 




Consumer D at abases + Reference D atabase & 

Proxy (Consum er ID, Proxy 

Customer/Wallet Mapping, (Products, Tariffs, etc) 
Product Instance) 



© Gomergvs. 2002 Confidential CONVERGYS 



Figure 28 



CinLibrary/1221 196.4 



Hydra: Real-Time Physical Architecture 
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Hydra: Real-Time Physical Architecture 
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Hydra: Real-Time Ph ysical Architecture 

Resubmit Server. Resubmits requests 
that timeout due to any server failure, 
provided the request has been marked 
for resubmission. 
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Hydra: Real-Time P hysical Architecture 

API Server: All CSR/CRM/Serf-care requests 
handled by API servers. 
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Hydra: Real-Time P hysical Architecture 



API Server: Updates Consumer Databases as a result of API 
change requests via Database Proxy. Reads Information 
from EveM manager (e.g. unbilled usage queries), and 
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Hydra: Real-Time Physical Architecture 
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Work Managers . Each pool of servers (Consumer Server, 
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Hydra: Real-Time Physical Architecture 



System support and Audit: Support processes including: 
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Scenario 1 - Roaming 
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Scenario 1 - Roaming 
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US Router Complex routes requests from 
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Routing may be algorithmic (e.g. IMSIs 
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Scenario 1 - Wallet shared across data centers 
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Scenario 1 - Wallet shared across data centers 
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Scenario 1 - Wallet shared across data centers 



"WSjTets from which a consumer ID can consume are 
tagged with both the Logical Data Store (which 
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Scenario 1 - Wallet shared across data centers 
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Scenario 2 - Single network, multiple data centers 
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CONSUMER SERVERS 
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WALLET SERVER 



CS WALLET FRAGMENT 

Fixed at creation by wallet server: 

• CS pool element ID 

• Fragment number 

• Wallet version 

Updated from WS as part of loan protocol 

• Fragment state (open/closed...)- 

• Fragment loan value 

Changed by rating, passed to CS log, also 
sent to WS directly as part of loan protocol 

• This charge 

• Fragment balance inc charge 

• Fragment change seq. number 

• Audit values [TBD] 
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CS WALLET FRAGMENT 

£ixed at creation by wallet server: 
CS pool element ID 
Fragment number 
Wallet version 



Updated from WS as part of loan protocol 

• Fragment state (open/closed.. .). 

• Fragment loan value 

Changed by rating, passed to CS log, also 
sent to WS directly as part of loan protocol 

• This charge / 

• Fragment balance inc charge 

• Fragment change seq. number 

• Audit values [TBD] 
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WALLET IN WS 

Fixed at creation: 

• WAI& Wallet number 

• Max wallet resource 

• Start/End dates (Jan t Feb, or 
forever) 
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CS WALLET FRAGMENT 

Fixed at creation by wallet server: 

• CS pool element ID 

• Fragment number 

• Watlet version 

LOAN PROTOCOL 

Updated and sent to CS via loan protocol 

• Local fragment state (open/closed...). 

• Fragment loan granted value 

Received from CS via loan protocol (used 
for loan calculation only): 

• Fragment balance 

• Fragment change seq. number. 

• Remote fragment state. 

FROM CS, VIA EM AND/OR WS 
Fragment balance from CS 
Last fragment sequence number from 
CS 

/AUDIT FROM CS WITH LOCAL CHECKS 
Fragment balance locally calculate by 
summed deltas 

Number fragments accumulated 
Reported balance in current day 
Calculated balance in current day 



Usage in WS, not in any CS: 

• WS local usage 

• Adjustments (etc) 

Wallet audit values 

• Cyclic audits [TBD] 

• Audits based on event DTM 

Billing values (may be stored elsewhere) 

• Values accumulated as to part of 
wallet. E.g. value of wallet based on 
ES data at end of last bill. 
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CONSUMER SERVERS 

Consumer 
Server TV 



WALLET SERVER 



CS WALLET FRAGMENT 

Fixed at creation by wallet server: 

• CS pool element ID 

Updated from WS as part of loan protocol 

• Fragment state (open/closed...). 

• Fragment loan value 

Changed by rating, passed to CS log, also 
sent to WS directly as part of loan protocol 

• This charge 

• Fragment balance inc charge 

• Fragment change seq. number 

• Audit values [TBD] 
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Fixed at creation by wallet server: 

• CS pool element ID 

Updated from WS as part of loan protocol 

• Fragment state (open/closed...). 

• Fragment loan value 

Changed by rating, passed to CS log, also 
sent to WS directly as part of loan protocol 

• This charge 

• Fragment balance inc charge 

• Fragment change seq. number 

• Audit values [TBD] 
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• Max wallet resource 

• Start/End dates (Jan, Feb, or 
forever) 

WS WALLET FRAGMENT 
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• CS pool element ID 

LOAN PROTOCOL 

Updated and sent to CS via loan protocol 

• Local fragment state (open/closed . . . ). 

• Fragment loan granted value 

Received from CS via loan protocol (used 
for loan calculation only): 

• Fragment balance 

• Fragment change seq. number. 

• Remote fragment state. 
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Usage in WS, not in any CS: 

• WS local usage 

• Adjustments (etc) 

Wallet audit values 
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• Audits based on event DTM 

Billing values (may be stored in different 
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• Values accumulated as to part of 
wallet. E.g. value of wallet based on 
ES data at end of last bill. 
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Hydra: Near Real Time Processing Detail 
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Hydra: Near Real Time Processing Detail 
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Hydra: Near Real Time Processing Detail 
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Hydra: Near Real Time Processing Detail 
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Hydra: Near Real Time Processing Detail 
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Hydra: Near Real Time Processing Detail 
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Hydra: Near Real Time Processing 
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Hydra: Near Real Time Processing Detail 
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Hydra: Near Real Time Processing Detail 
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Hydra: Near Real Time Processing Detail 



Hydra APIs allow external 
system* to receive and 
acknowledge CoS file streams. 



Consumer 
Servers 




D atabase (E M F CO ) Everts 



© Con vergy?. 2002 Confidential CONIVCRGYS 



CinLibrary/1 22 1196.4 



Hydra: Near Real Time Processing Detail 
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Hydra: Near Real Time Proc 
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Hydra: Near Real Time Proces: 



All servers {EM, ES, WS) mailt ain a 
watermark per CS of the last event 
processed. This includes CS process 
sequence and CS process date. Used to 
verify data has flushed into stores prior 
to billing. (More discussion here ...) 
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